On Wed, Jul 20, 2022 at 7:06 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > At Tue, 19 Jul 2022 14:28:40 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in > > Hi, > > > > At times it's useful to know the last replayed WAL record's timeline > > ID (especially on the standbys that are lagging in applying WAL while > > failing over - for reporting, logging and debugging purposes). AFICS, > > there's no function that exposes the last replayed TLI. We can either > > change the existing pg_last_wal_replay_lsn() to report TLI along with > > the LSN which might break the compatibility or introduce a new > > function pg_last_wal_replay_info() that emits both LSN and TLI. I'm > > fine with either of the approaches, but for now, I'm attaching a WIP > > patch that adds a new function pg_last_wal_replay_info(). > > > > Thoughts? > > There was a more comprehensive discussion [1], which went nowhere.. > > [1] https://www.postgresql.org/message-id/20191211052002.GK72921%40paquier.xyz Thanks Kyotaro-san for pointing at that thread. Infact, I did think about having a new set of info functions pg_current_wal_info, pg_current_wal_insert_info, pg_current_wal_flush_info, pg_last_wal_receive_info, pg_last_wal_replay_info - IMO, these APIs are the ones that we would want to keep in the code going forward. Although they introduce some more code momentarily, eventually, it makes sense to delete pg_current_wal_lsn, pg_current_wal_insert_lsn, pg_current_wal_flush_lsn, pg_last_wal_receive_lsn, pg_last_wal_replay_lsn, perhaps in the future versions of PG. Thoughts? Regards, Bharath Rupireddy.